fix(pi): emit parameters and execute in the generated pi adapter - #1678
fix(pi): emit parameters and execute in the generated pi adapter#1678musichen wants to merge 7 commits into
Conversation
The generated Pi extension registered each MCP tool as { name, run }, but
Pi's ToolDefinition requires label, description, parameters, and execute.
Tools registered that way carried no parameter schema, so strict providers
such as xAI/Grok reject the request with a 422 'missing field parameters',
and the tools were uncallable because Pi invokes execute, never run.
Emit the full tool shape from the registry: label/description via new
accessors, the input_schema embedded directly as a JSON object literal, and
execute instead of run.
Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
|
Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. Current review status: working through a backlog. What that means for this PR, concretely:
Things that will genuinely speed it up whenever review does happen:
If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. |
The generated execute forwarded the raw MCP JSON directly, but pi's
ToolDefinition.execute must return { content: [{ type: 'text', text }],
details } — a result without a content array crashes the TUI's
getTextOutput on result.content.filter(...).
Request raw JSON from the CLI ('--json') so the bridge parses the MCP
result instead of the human-readable text, then wrap it: pass the content
array through, throw on transport errors, and stringify anything else.
Adds coverage asserting the corrected execute shape and the --json flag.
Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
clang-format wants no spaces inside a braced initializer. Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
|
We took this to the plausibility gate's end-to-end step before merging, and the probe against the current published Pi (@mariozechner/pi 0.70.6, fresh npm install) found the contract has moved under the PR — sharing the specifics because your three diagnosed breakages are real and the fix direction is right:
The mixed match suggests you validated against a different Pi build (understandable — 313 published versions). Could you tell us which version you ran the TUI against, and whether current Pi still loads TS tool extensions at all (vs. having moved on)? If extensions are alive in some form, we'd take a revision targeting the current AgentTool contract with the version noted in the generated header; if Pi has effectively dropped this surface, the honest fix may be retiring the adapter in favor of whatever Pi consumes now — which we'd also want to know. Thank you for the careful three-part diagnosis either way; it's the reason this got a real probe instead of a rubber stamp. |
|
The three breakages you listed were real on the coding-agent surface I was looking at. I ran against Small local context, since this is easy to miss from outside: I am in Vienna, same city as Mario / the Pi community here. Around three months ago (May 2026) it was going around locally that Mario Zechner joined Earendil GmbH and that Earendil took on pi.dev. That matches the packaging cut I can actually point at: 0.73.1 / 0.74.0 on 2026-05-07 (
Answers to the three points:
That finding is correct for The older coding-agent name on that scope is On 0.84.2, TS extensions are still a first-class surface:
So I would not retire the adapter. The install target for a re-probe should be
Yes. That was a real bug in this PR, and it is still true one wrapper up on 0.84.2 execute(
toolCallId: string,
params: Static<TParams>,
signal: AbortSignal | undefined,
onUpdate: AgentToolUpdateCallback<TDetails> | undefined,
ctx: ExtensionContext,
): Promise<AgentToolResult<TDetails>>
async execute(toolCallId, params, signal, _onUpdate, ctx) {
const result = await call(name, params, signal ?? ctx?.signal);
...
return { content, details: result ?? {} };
}and the generated header pins
Agreed. That half was already correct and is unchanged. A probe can be re-run against |
Pi 0.84.2 calls execute(toolCallId, params, signal, onUpdate, ctx). The generated (args, ctx) shape bound the call id as the MCP arguments. Forward params and signal, pin the @earendil-works/pi-coding-agent contract in the generated header, and lock the 5-arg form in tests. Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
DeusData
added
bug
|
Thank you for correcting the package target and updating the We will re-probe the generated adapter against the exact coding-agent version and extension contract you identified before making a merge decision. The process-spawn path is an existing adapter boundary rather than a new service dependency, but its argument order, cancellation signal, result normalization, and generated-string escaping all need end-to-end verification. Thank you for answering the version question with enough detail to make that probe reproducible. |
|
Thanks. Branch is synced with Re-probe target I used, so the next run is on the same surface:
String shape and path escaping are already in An in-tree fixture for arity + wrap is easy to add if that is cheaper than a TUI session. |
2 participants
Problem
The generated Pi extension (
~/.pi/agent/extensions/cbmem.ts) registers each MCP tool as:Pi's
ToolDefinitionrequireslabel,description,parameters, andexecute. Therun-only shape is accepted by Pi's loader but produces tools that fail in two ways:parametersschema - strict providers such as xAI/Grok reject the request with422 missing field parameters(OpenAI and other providers tolerate the omission, so it only surfaces on some providers).execute- the tool is uncallable, because Pi invokesexecute, neverrun.Once
executewas wired up, a third problem surfaced:executeforwarded the raw MCP JSON (which has nocontentarray) instead of Pi's required result shape, crashing the TUI'sgetTextOutputonresult.content.filter(...).Fix
The adapter now emits the full tool shape from the registry:
Specifically:
cbm_mcp_tool_titleandcbm_mcp_tool_descriptionaccessors so the adapter reads metadata from the same registry that backstools/list, instead of drifting.input_schemais embedded directly as a JSON object literal (compact JSON is valid JavaScript), avoiding aJSON.parseindirection.callnow passes--jsonso the CLI emits the raw MCP result instead of human-readable text thatJSON.parsecannot parse.executereturns Pi's required{ content, details }shape: it passes the MCPcontentarray through, throws on transport errors, and stringifies anything else.Tests
client_adapter_pi_emits_parameters_and_executeassertingexecute/parametersare present, the legacyrun:shape is gone, the schema is embedded, and--jsonis requested.cbmem.tsloads and returns a valid result shape for success, error, null, and plain-object results.agent_clientssuite: 32/32 passing.